Night Owl 6

home *** CD-ROM | disk | FTP | other *** search

/ Night Owl 6 / Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso / 033a / rypack41.zip / RYPACKER.DOC < prev next >

Wrap

Text File | 1991-10-08 | 35KB | 826 lines

RyPacker: A FidoNet Interface for the RyBBS/RyMULT BBS Software System Reference Guide by Greg Ryan (C) Copyright 1991 Original Rypacker design and docs by John Gemmill I. Introduction Disclaimer, etc. I am providing this software and its associated instructions and demonstration files for distribution under the shareware concept. If you wish to continue using it after a suitable evaluation period, you are expected to pay for it. Your conscience will let you know when you're done evaluating it. The current price is $25.00, which should be paid by check, Visa or MasterCard. You may contact me through FidoNet 154/333 or register on-line at (414)-962- 1097. I will try to answer any questions and implement any suggestions with which I am provided. I stand behind RyPacker! RyPacker is not intended to do nasty things to you or your computer, nevertheless I assume no responsibility whatever for any damage whatsoever to you or your computer system resulting from the use of this software (I have to say that). Please see the accompanying NEW.DOC file for the latest additions and improvements. I am assuming: 1) You have some familiarity with FidoNet (everyone reading this should anyway), 2) that you have been set up with a node (at least a temporary one), and 3) that you have set up some kind of packet handling system such as BinkleyTerm (see the Supplementary Files section, below). What Is RyPacker? RyPacker is a message converter designed to convert the RyBBS message format to the FidoNet "standard" message packet format, thus allowing a RyBBS system to interface with the FidoNet network (The reader is referred to the Basic FidoNet(tm) Technical Standard Draft FSC001-9 or NEWSYSOP.TXT, available on many FidoNet BBSes, for a discussion of the current standard; all FidoNet persons should be familiar with these documents! See the section on Supplementary Files, below). Rypacker has the following functions: 1) Scan selected message bases and convert new messages to outbound Fido message packets 2) scan a DOS directory for inbound message packets and convert the messages to RyBBS format 3) Check configuration file for correct syntax. RyPACKER Reference Manual 2 The current version of Rypacker will not handle any complicated routing schemes; instead, routing is left for external utilities (such as oMMM) to handle. RyPacker will address messages to different nodes and does have facilities for handling echo mail. How Does RyPacker Work? In its inbound (unpack) mode, RyPacker will accept a directory name (note that all directory names default to the current directory) and scan that directory for files of the form *.PKT. Such files are assumed to follow the FidoNet packet standard (see the FSC docs) and, as such, contain messages for unpacking. Sometimes packets are generated which contain no real messages, usually for file transfers; at present, RyPacker will ignore these. Any messages in the packets are examined to determine which message base they are for. A DUMP message base (see the Commands sections, below) should be provided for messages that RyPacker is unable to deliver. A mechanism is provided to translate names which are inappropriate external to RyBBS, such as 'SYSOP' or any funky handles (unacceptable on FidoNet) your users might have. If a message comes in without an AREA: line as its first line, the RyBBS USERS.BBS file will be scanned to determine if the addressee is a valid BBS user. If so, that message will be put into the RyPacker EMAIL message base, if one is specified. If the message has a valid AREA: line then RyPacker will put that message into the area specified by the matching AREA command. If a message has more lines than the maximum specified in the STARTUP.BBS file (see the RyBBS/RyMULT documentation). The message will be split, the header will be duplicated, and RyPacker will provide the necessary hooks for RyBBS to effect threads. Note that at present the inbound packets are NOT deleted (for safety's sake and to check that RyPacker is unpacking correctly) and some provision should be made to empty out the inbound directory! (Usually a del *.pkt command from the batch file) In its outbound (pack) mode, RyPacker will accept a message base number (see the config file commands section, below), grab the filename from RYBOARDS.BBS, and scan that base for new messages from the point it left off previously. Each RyBBS message appropriate for transmission is translated into a Fido standard message and put in an outbound packet file (one for each destination; may contain multiple messages) with the filename of the destination net/node in hex (something like 007D014D for 154/333) and an .OUT extension. The *.OUT files are then handled by oMMM/Binkleyterm (or what-have-you). The first time you run RyPacker, it assigns itself a definable user record to use with the RyBBS *.PTR files to keep track of its last messages. In that respect, it is treated by RyBBS exactly as a normal user and utilities such as RPACK will delete RyPACKER Reference Manual 3 RyPacker from the user list if you're not careful!. Note that if RyPacker cannot find itself in the user list, ALL messages in ALL the message bases listed in RyPacker's config file will be packed! Also, if a user has a way to list the current users, RyPacker will appear in the list. I plan in the future to have RyPacker send messages to users when their network messages contain errors, so try to pick a meaningful name for RyPacker to use (defaults to 'RyPacker' with a password of 'Sexually'). The usage implies that a separate inbound and outbound set of subdirectories should be created, which is the format supported by oMMM and BinkleyTerm and is the setup I use. Once the outgoing packets are sent, they are deleted by BinkleyTerm and the outbound directory is left empty, ready to go again. At present, RyPacker will not bundle separate packets for routing to a single node; the packets will each contain messages to the net/node for which the messages are intended. This job is left to message routers such as OMMM. The SYSOP should be familiar with the Fido network standards enough to help unfamiliar users 'get the message across.' RyPacker will look on the first line of the message for the keyword TO: and, if present, assumes that the following characters make up a valid Net/NODE address. At this point, no provisions are made to scan the nodelist to check validity; if the numbers ARE numbers and are separated by a slash ('/') then the message is addressed to that node. At the end of the message, RyPacker appends a standard Tear line and an Origin line containing the text specified in the Origin command (which defaults to '(your_net/your_node)' if not specified). This should be something meaningful to everyone who sees the message and provide a way to respond. I recommend that you give your BBS name, phone number, software (RyBBS/RyMULT!), and node number (this last is supposedly required for FidoNet). RyPacker will then append a Seen-by line with your net/node and the destination('s) (net(s))/node(s). RyPacker will also handle simple routing (i.e. correct Seen-by information) for messages originating on its RyBBS only. I hope in the future to implement external message routing and cost features like those of the Opus BBS system and Binkley/oMMM packet handlers, but don't hold your breath. RyPACKER Reference Manual 4 Program Usage RyPacker is invoked by the command: RyPacker [/p][b#,m#[-m#]] [/u] [/c] [/l] [filename] where all the command line parameters are optional and are as follows: /p turns on the pack mode /u turns on the unpack mode /c turn on syntax checking /l turns on file locking (Be sure that Dos SHARE is active) filename is the optional DOS filename to be assigned to the RyPacker configuration file. Note: if you run Rypacker without any command line parameters a simple help screen will appear. In the packing mode the optional b# and m# stand for board number and message number, respectfully, and, if specified, will invoke the single-base message repack feature (explained in detail below; note that if b# is specified the comma following b# is NOT optional and that there is NO SPACE between p and b#!). If both 'p' and 'u' are specified, the pack routine will execute first. This is because the high message pointer is set to the last message when messages are unpacked; if you defeat this safety feature from the command line, outgoing messages might not make it out!! The optional single-base message repack feature allows you to repack one or more messages anywhere within a single message base. Examples: rypacker /p Pack all messages in all applicable Rypacker bases. Place all outgoing packets in the outbound directory. rypacker /u /l Unpack all message packets located in the inbound directory in all applicable Rypacker bases. Use file locking for all file accesses. RyPacker /P10,300-350 repack.cfg packs messages 300-350 in message base 10 using repack.cfg file; rypacker /c Check syntax of current rypacker.cfg file for correctness. rypacker /P20,2 packs (only!) message 2 in message base 20 using (default) rypacker.cfg file; RyPACKER Reference Manual 5 RyPacker P3 U rconfig1.cfg pack message base 3 As you can see you may specify different config files. This allows you to have multiple configurations, for any reasons you might have (I, currently, have none, but it's a neat feature). You can run RyPacker from your RyBBS control batch file and pack/unpack different bases at different times. You can set up different commands and switches in the config file for different RyMult nodes and message bases. Someone could be clever and set up some NEAT routing features this way. Be creative, and let me (and everyone else) know what you create! The defaults are: neither mode (pack nor unpack) and RYPACKER.CFG. Be warned: Anything other then a valid command parameter will be interpreted as a config filename. If you hit 'o' instead of 'p', like: rypacker o charlie.cfg, then 'o' is your config file as far as RyPacker is concerned. In most cases, this will be an error and RyPacker will halt. I've tried to write informative error messages; if it's a runtime error, look in the Turbo Pascal 4.0/5.0 manual (everyone should have one...) and that may help you fix it. RyPacker uses many dynamic memory structures, so don't assume you can run it in a small memory configuration. I have successfully run RyPacker remotely with the X00 driver, one copy of RyMULT and, of course, a second COMMAND.COM in memory through the (RyMULT) EXEC command. Since my intended use is from the BBS control batch file at a time when the BBS is inactive, the memory restrictions should not prove to be a serious limitation. In a multi-node setup at least one node would have to go down anyway to access Fido, which should leave enough memory for RyPacker. As I've alluded to, since RyPacker does support file locking, so it will work just fine with RyMULT, RyBBS's big multi-user brother. RyPACKER Reference Manual 6 RyPacker Configuration Options Rypacker receives most of its' commands from the configuration file. The default configuration file is named Rypacker.cfg. RyPacker will interpret the following commands from an ASCII text configuration file. Be advised that all directories default to the current directory): RYBBS_DIR d:\path\ Specifies the directory where the RyBBS system files are located (specifically, RyBOARDS.BBS, and STARTUP.BBS). The d:\path\ specifier can be any legal DOS drive and path. OUTBOUND d:\path\ INBOUND d:\path\ Specify the directories where inbound and outbound mail packets can be found. BinkleyTerm will share these directories. Remember to empty the inbound directory from your control batch file after RyPacker is done!! USER_PATH d:\path\ Specifies the directory where the USERS.BBS and USERS.PTR files are located. This is usually the same as the RYBBS_DIR path (above) however in the multi-user (especially LAN) setup it can be something else (often on a different drive!). AREA board_number area_name [net/node* node*] Sets up an association between a RyBBS message base and a FidoNet area name. This is used to implement echomail facilities. Incoming mail with a first line of AREA:areaname (a Fido standard) will be unpacked and put into board_number (from RyBoards.BBS) and any new messages in board_number will receive a first line of AREA:areaname before being packed for FidoNet. The net/nodes listed will be the message addressees (multiple listings may occur on one line; * = repeat any number of times as in BNF notation; see the sample config file for examples). The special area_name DUMP specifies the message base which will receive any undeliverable messages. EMAIL board_number Specifies the RyBBS EMAIL board which will receive messages that have no AREA: line and are addressed to BBS members (i.e. names in USERS.BBS file; others go to DUMP). ORIGIN net/node Specifies your Fido net/node address; used to identify the originating BBS in any outgoing Fido messages. ORIG_TEXT "text" Defines the text to be used on the * Origin: line which follows the actual message text of a FidoNet message (defaults to '(orig_net/orig_node)'). This can be anything RyPACKER Reference Manual 7 you want, but should include your network address and is most useful as a system identifier. Note the surrounding quotes. USER_NAME name Defines the name which RyPacker will use for itself in the USERS.BBS file (defaults to 'RyPacker'). USER_PW password Defines the password for RyPacker to use for itself in the USERS.BBS file (defaults to 'Sexually'). RyPacker automatically assigns itself a security of 100 in an attempt to prevent accidental deletion. NAME internal_name:external_name Implements a name translation facility. You can use this to eliminate handles (which are frowned upon) from FidoNet, but at the same time preserve them on your BBS. You should at least have one line that reads NAME SYSOP:(your name) so that messages addressed to you on Fido will be addressed to SYSOP on your BBS. MESSAGE_THREADS With this switch, RyPacker will look backwards through the message base to find subject fields that match the current incoming message subject and set threads accordingly (default is OFF). Works only for new incoming messages (will not thread messages previous to INVOCATION). STRIP_SEENBY With this switch, RyPacker will strip the space hogging seen-by lines when unpacking messages (incoming only!; default is OFF). *** WARNING! *** This command could have *DISASTROUS* effects on routing if you repack messages that have been stripped of seen-bys!! If you are an echo feed node (i.e. you send echoes to other systems besides your feed), use an auxiliary message router/passer such as BearScan or ConfMail. Alternatively, you could set up a special pass-through message area that's not accessible to RyBBS and not strip seen-bys to that area. NO_USAGECOUNT This switch turns off incrementation of the timeson field in the RyPacker user record of USERS.BBS. With this command, RyPacker will not show up in a count of users logged on to RyBBS. NO_PROPERNAMES This switch turns off proper names conversion. Without it (i.e. default is ON), RyPacker will effect proper name conversion to all outgoing names, changing the RyBBS all uppercase name format to the more conventional proper format RyPACKER Reference Manual 8 (only first letters uppercase). Who knows what will become of VAN DER MEER ;-). LOGFILE This switch turns on the logfile facility (default is OFF). The logfile will keep track of what RyPacker is doing, but it gets large quickly. NOSCREEN This switch will turn off output to the screen (i.e. things will run a bit faster and if no one's there to watch, why bother with screen I/O??; default is ON). Included with this package you will find a sample copy of a RyPacker.CFG file from which you may glean some useful tips. RyPacker Internal Message Commands In addition to the config file commands, RyPacker will recognize several commands within messages. These commands and their usage should be made known to your users. NOSEND RyPacker will NOT send a message that has this word (ONLY!) as its first line. Handy for leaving instructional messages to your users in a Fido message area. TO:net/node This is the way NetMail messages are routed using RyPacker. Messages may be [R]eplied to and automatically be sent to the correct address without adding a new TO: line. RyPacker handles this by putting an ORIGIN line at the beginning of each message from which the [R]eply address is taken. If the old message isn't there, the [R]eply won't get sent (unless it has a TO:, which isn't automatic). This doesn't mean it can't be deleted, just run RyPacker before rpack. BBS software like Opus has provisions for prompting the user for the addressee net/node and then scanning the nodelist and assessing charges. Since RyBBS is fully internal in its message format, no provisions exist for routing network email or charging for long distance calls. If RyPacker sees this command, a message packet WILL BE CREATED for that node; if your Binkley/oMMM (or whatever) routing package and nodelist are set up in such a way that a message could be sent to Alaska when you're in Florida, watch out. For this reason, my nodelist contains ONLY local numbers. There are provisions in Binkley which can provide long distance message routing with PCPursuit during off-peak telephone hours; just be sure to watch your system closely! I may be implementing features to check the cost of sending a message, as well as a system to inform users that their message was undeliverable as written. You need to inform your users of the correct usage of this command to insure that your BBS works properly with FidoNet and RyPacker! RyPACKER Reference Manual 9 Error Conditions Command Line Error -- RyPacker halts! (no comma, etc.....). The actions of this command will not affect RyPacker's high message pointers so if you run this command before a regular pack command you could end up packing messages twice (!). If the message base does not exist in RyPacker's config file, you can be assured that absolutely nothing will happen. If the ending message number is greater than the highest message in that base, all messages to the end will be packed. If the starting message is greater that the highest, well, what point was there to invoking RyPacker (it does nothing...)! If you think I start too many sentences in a row with "if," well, you may be right ;-). Logistics I have put the RyPacker command in my BINK.BAT file (the Binkley control batch file for my system) to be called each time mail is received or right before nithttime mail call. You can set your system up so that RyPacker is only activated once-a-day to pack and unpack messages, say during normal system maintenance. Alternatively if you wish the outbound areas to be as current as possible and you have mailers calling you during different hours of the day you can have several timed events that will pack mail at different hours. Remember that RyBBS supports timed events, which will close down the BBS and drop to DOS. RyPacker lives in its' own directory on my system and although that's not required, you may benefit from assigning RyPacker its own directory. Since I have maintained a fully qualified (directory-plus-filename) format for all the files in RyPacker, it should be able to find all the files it needs from anywhere. If this turns out not to be the case, I want to know about it! RyPacker is designed as an interface for the RyBBS BBS system so obviously that system is required to use RyPacker. If you don't already have it, the RyBBS package may be obtained from: RyBBS HomeBase (414)-962-1097 (2 lines 962-1098 is my Fido Node 154/333) RyPACKER Reference Manual 10 Fido Info Just to give you an idea of what FidoNet is: "... [The FidoNet Network] is a loose coalition of many different bulletin board systems. 'FidoNet' and 'Fido' are registered trademarks of Tom Jennings.... " That quote is from the New- SYSOP Orientation Information document put out by the International FidoNet Association (IFNA), available as NEWSYSOP.ARC. This document explains what FidoNet is all about and gives some guidelines for persons interested in becoming FidoNet participants. It is available for download (or file requesting) on many Fido BBSes. This is the place to start if you have no idea what FidoNet entails. The IFNA has also put out a series of more technical documents which detail the technological aspects of FidoNet. I have used the "standards" set forth there to write RyPacker. There are many exceptions to those "standards" (hence the quotes) which make interfacing to FidoNet a difficult task. You will doubtless experience problems getting things to work and the more you know about what's SUPPOSED to be going on, the better equipped you'll be to make corrections. This series of text files constitutes a small (?) book, but the information contained therein is the heart of the FidoNet network. Since RyPacker is intended only as a message format translation facility, some additional system is necessary to interface with the outside world and actually send and receive messages over FidoNet. I am currently using BinkleyTerm by Bob Hartman and Vince Perriello, available as BEXE_nnn.ARC where nnn is the version number (i.e. BEXE_230.ARC for v2.30). BinkleyTerm is "A Free-for-the- Asking FidoNet Compatible Electronic Mail Interface...." All it does is send out and receive mail packets (and act as a dumb terminal), but it does that very well. BinkleyTerm is a whole world unto itself and you will need to spend some time to get it working properly. It will handle all the telephone line transfer aspects of FidoNet, from answering and dialing the phone through distributing mail to handling file transfers. It requires a FOSSIL (Fido/Opus/SEAdog Standard Interface Layer) driver to handle the modem. I can recommend the x00 (Copyright (c) 1987 by Raymond L. Gwinn) or the BNU (Copyright (C) 1989 David Nugent & Unique Computing P/L) systems for this purpose; look for X00nnn.ARC or BNUnnnn.ARC (or ZIP or whatever) where nnn is the version number. I normally have Binkley running as my 'front end' system for my second node (I run a two node system) so it ALWAYS answers the phone. If a regular (non-mail) user calls the board Binkley drops out and loads up RyMULT immediately using the /B command option. After the user logs off the RyMULT program exits and the batch file will automatically load Binkley again. Check the RyBBS docs for more details about this. RyPACKER Reference Manual 11 The files which control mail flow using Binkley can be generated and maintained with a program called oMMM, the Opus Matrix Message Masher (by Wynn Wagner & Bob Hartman), available as oMM-130.ARC (or ZIP or ZOO or Who Knows What Current Archiver...). This program will handle routing your packets (different from message routing) and will generate files that Binkley can use to poll for mail. The documentation for oMMM is part of what I have found to be the best description of FidoNet yet: The Opus Documentation for System Operators, available as O_SYSDOC.ARC. oMMM will also handle Opus messages and create packets from them. FidoNet is held together by a thing called the nodelist. This is basically the Fido phone book. In order to enter the FidoNet world, you will need a current version of the nodelist and your own net/node number assignment. The first step towards becoming a FidoNet participant is to contact your local area network (NO pun intended) coordinator and request a node number. You can usually find your local coordinator by finding a local Fido BBS, which can usually be found by examining a BBS listing, which can usually be found by calling a BBS (if you're lost at this point, check a computer store). Be sure to let your local Fido BBSes know that you are just starting out and will be testing your system. They'll know what you're going through and be more than happy to assist. In order to use the nodelist with BinkleyTerm (or most any packet handler) you will need some way to change its format. A good nodelist parser is the XLAXNODE II system (Copyright 1987, 1988 by Scott Samet). It will allow you to build a nodelist which will virtually eliminate any possibilities that your system will generate any long distance calls without your approval. There are also a handful of utilities that will allow users to check the nodelist for addresses through a DOS door. Check around and ask on some local Fido boards. One other file you should try to locate is a test packet for you to experiment with RyPacker and Fido. If you ask your coordinator to hook you into a national echo you will receive many packets. You may want to limit your initial network activities to inbound messages only until you're sure everything is working properly; just don't let Binkley have access to any outbound packets created by RyPacker. You should also generate some test packets of your own on your own system using RyBBS and RyPacker; remember that the packet files will be named with the hex number of the addressee net/node. You can check that RyPacker is functioning by unpacking these test packets into your message base. They should look like the original messages you entered with the addition of the tear and origin lines. Be warned that BinkleyTerm will rename all incoming packets to avoid name collisions so that those packets won't necessarily look like they're addressed to you. RyPACKER Reference Manual 12 To summarize, I list the files necessary in addition to RyPacker (please substitute the appropriate archive extension for ARC in the following -- ugh!): RyBBS/RyMULT RyBBS BBS system FSC-ALL.ARC FSC technical docs NEWSYSOP.ARC New-SYSOP introduction O_SYSDOC.ARC The Opus docs for SYSOPs BEXE_nnn.ARC BinkleyTerm packet handler oMMM-nnn.ARC Opus message & packet handler X00_nnnn.ARC FOSSIL driver BNU_nnnn.ARC Another FOSSIL driver NODELIST.ARC Current nodelist (changes weekly; name may differ) NODEDIFF.ARC Changes to the nodelist (issued weekly; name may differ) XLAX_nnn.ARC Nodelist parser nnnnnnnn.PKT Test packet(s) I may also recommend two utilities useful for dealing with file transfers (known as File REQuests and File ATTaches (FREQs and FATTs): NSEND and NGET, which are just pieces of the Opus system chopped off to be used separately. Check your local boards and ask around; there are others in this same vein. I would also like to plug two little utilities written by John Gemmill. BulReset.EXE, which just resets selected bulletin flags from the command line, and RyDelOld.EXE, which will delete messages older than a date you specify and/or limit a message base to a certain number of messages, again completely command line driven (both are available on HomeBase BBS). The latter is quite useful for echomail message bases as they tend to fill up rather quickly. Thanks to John Gemmill for starting this project. RyPACKER Reference Manual 13